1. Technical Field
The present invention relates in general to a system and method for simulating software conditions. More particularly, the present invention relates to a system and method that simulates conditions, such as error conditions and results, that can alter control flow in an executable software module.
2. Description of the Related Art
As software is developed, it needs to be tested in various phases, including, for example, unit testing of each module, integration testing of related modules, function verification testing, system verification testing, etc. A complete test of a piece of software should ideally involve testing the flow of control in all correct conditions, as well as all possible error conditions. However, it is extremely difficult, if not impossible, to easily reproduce all possible conditions. For example, certain error conditions, such as a time-out condition from a server, require a complex testing environment. Code-paths representing unusual, but legal, conditions may be hard to reproduce. Due to the difficulty in reproducing and testing some obscure conditions, developers often test only a small subset of important, or easy to reproduce, errors, while the behavior of the software in response to all other errors remains untested. This is a liability to software companies, which then need to provide support and/or fixes to their customers as and when bugs are discovered.
One technique for testing software error handling is to manually reproduce errors, and test to see if the software behavior in response to these errors is per specification. However, this technique requires a considerable investment of time and effort to reproduce error conditions and then recover from the error. Also, as discussed above, some errors, such as server time-out errors, are difficult to reproduce. Another error handling testing technique is to modify function arguments, return codes, or parameters during run-time and thus create the error conditions of interest. A drawback to this approach is that a debuggable version of the executable software code needs to be available. Most software executables are not shipped in a debug-ready mode due to the large size of the debuggable version of the executable. Hence, this approach is often not available to solve customer problems at the customer's location. Also, this type of testing can not be automated. For each run of the test-case, the relevant variables must be manually modified through a debugger. Thus, this is typically a costly approach to testing.
Another testing technique, used during the development phase to test different code paths, is to hard-code variables in the source code in order to drive different code paths or branches of the code. This only works well during the development phase, and can not typically be automated, because it involves manual code changes and recompilation. Another approach to force different code paths is to change variables, arguments, etc. through the use of a debugger. However, as discussed above, this approach can not be automated, and also requires that a debuggable version of the executable code be available, which is often not the case at a customer site.
What is needed, therefore, is a system and method that reproduces errors and drives the control-flow in a software module in order to allow for more efficient and thorough testing of software systems.